System and method for detecting unused accounts in a distributed directory service

ABSTRACT

A distributed information processing system in an enterprise computer network comprising a collection of servers providing a directory service and a directory-enabled access control system is augmented with the ability to detect user accounts in the directory service for users who have not recently authenticated to an application that uses the directory-enabled access control system.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of PPA Ser. No. 60/838,077 filedAug. 16, 2006 by the present inventor, which is incorporated byreference.

FEDERALLY SPONSORED RESEARCH

Not applicable

SEQUENCE LISTING OR PROGRAM

Not applicable

BACKGROUND OF THE INVENTION

1. Field of Invention

This invention relates generally to management of identity informationheld in directory servers in enterprise computer networks.

2. Prior Art

A typical identity management deployment for an organization willincorporate a directory service. In a typical directory service, one ormore server computers host instances of directory server software. Thesedirectory servers implement the server side of a directory accessprotocol, such as the X.500 Directory Access Protocol (DAP), as definedin the document ITU-T Rec. X.519 “Information technology—Open SystemsInterconnection—The Directory: Protocol specifications”, or theLightweight Directory Access Protocol (LDAP), as defined in the document“Lightweight Directory Access Protocol (v3)”, by M. Wahl et al ofDecember 1997. The client side of the directory access protocol isimplemented in other components of the identity management deployment,such as an identity manager or access manager.

A directory access protocol follows a request-response model ofinteraction, in which the client establishes a connection to a directoryserver, and over that connection, sends one or more requests. Thedirectory server processes those requests and sends responses over thatconnection. The types of requests in a directory access protocolinclude:

-   -   the bind request, in which the client sends its authentication        information to the server,    -   the search request, in which the client requests one or more        entries in the server's directory information tree be returned,    -   the modify request, in which the client requests that the set of        attributes be changed in an entry in the server's directory        information tree, and    -   the delete request, in which the client requests that an entry        be removed from the server's directory information tree.

In order to provide an anticipated level of availability or performancefrom the directory service when deployed on server computer hardware anddirectory server software with limits in anticipated uptime andperformance, the directory service often will have a replicatedtopology. In a replicated topology, there are multiple directory serverspresent in the deployment to provide the directory service, and eachdirectory server holds a replica (a copy) of each element of directoryinformation. One advantage of a replicated topology in an identitymanagement deployment is that even if one directory server is down orunreachable, other directory servers in the deployment will be able toprovide the directory service to other components of the identitymanagement deployment. Another advantage is that directory service queryoperations in the directory access protocol can be processed in parallelin a replicated topology: some clients can send queries to one directoryserver, and other clients can send queries to other directory servers.

Some directory server implementations which support the X.500 DirectoryAccess Protocol also support the X.500 Directory Information ShadowingProtocol (DISP), as defined in the document ITU-T Rec. X.519,“Information technology—Open Systems Interconnection—The Directory:Protocol specifications”, which specifies the procedures for replicationbetween directory servers that implement the X.500 directory accessprotocol.

In many large and multinational enterprises, the deployment mightincorporate multiple distinct implementations of a directory server, andthere may be directory server implementations that are not based on theX.500 protocols. Examples of directory server implementations that arenot based on the X.500 protocols include the Microsoft Active Directory,the Sun Java Enterprise System Directory Server, OpenLDAP directoryserver, and the Novell eDirectory Server. As there is currently nostandard replication protocol between directory server implementationsfrom different vendors that are not both implementing the X.500protocols, synchronization mechanisms are often used in addition toreplication protocols in order to maintain the consistency of directoryinformation between directory servers in the deployment. Synchronizationproducts, such as a metadirectory server, are used in enterpriseidentity management deployments that incorporate directory serverimplementations from multiple vendors. These synchronization productsinterconnect these directory servers, and transfer changes made in onedirectory server to another directory server, so that all directoryservers have copies of the data.

A primary component of the information model of a directory server isthe directory information tree. The directory information tree comprisesa set of one or more directory entries. Each entry has a distinguishedname that is unique amongst the entries in the directory informationtree. Each entry comprises a set of one or more attributes. Eachattribute has an attribute type, and there is at most one attribute inan entry of each attribute type. Each attribute has one or more values.Each entry has an attribute, objectClass, with one or more values thatare names of object classes defining the contents of the entry.

A directory schema defines the semantics associated with each objectclass and attribute type. The schema specifications for an object classinclude: the attribute types of attributes which must be present in anentry when the entry has that object class, and the attribute types ofattributes which may be present in an entry when the entry has thatobject class. The schema specifications for an attribute type include:the maximum number of values of the type which can be present in anentry, the syntax of the values of the attribute type, and how values ofthe attribute are compared with each other. The directory schema isrepresented in the directory as values of the two operational attributesattributeTypes and objectClasses, as described in the document“Lightweight Directory Access Protocol (LDAP): Directory InformationModels”, by K. Zeilenga, of June 2006.

The choice of schema to use in a directory server is determined by theadministrator of the directory server. Some directory serverimplementations have a single, fixed schema; others are extensible andpermit the administrator to add attribute type and object classdefinitions. Several recommended schemas have been published, includingthe documents ITU-T X.520|ISO/IEC 9594-6, “The Directory: Selectedattribute types”, ITU-T X.5211 ISO/IEC 9594-7, “The Directory: Selectedobject classes”, “Definition of the inetOrgPerson LDAP Object Class” byM. Smith of 2000, “Lightweight Directory Access Protocol (LDAP):Directory Information Models” by K. Zeilenga of June 2006, and“Lightweight Directory Access Protocol (LDAP): Schema for UserApplications”, by A. Sciberras of June 2006. In each of these schemas, auser of directory-enabled applications is represented by a single entry.The set of allowed attributes of the object class for such an entryinclude an attribute which comprises the authentication credentials ofthe user, such as the user's password. For example, the ‘inetOrgPerson’object class allows the attribute userPassword, which contains thepassword of the user represented by an object of that class.

A metadirectory, as described in U.S. Pat. No. 7,191,192 B2 toYellepeddy et al, is a software product which translates the contents ofone data repository to be appropriate for use in another repository, inwhich the data repositories may be directory servers or other forms ofdatabases. One primary use of a metadirectory is the translation ofdirectory entries from one schema to another, for deployments in whichtwo or more implementations of directory servers are present, and thedirectory servers have fixed incompatible schemas.

A directory proxy server is a specialized server which implements adirectory access protocol, typically LDAP, but does not maintain a copyof the directory information tree. Instead, the directory proxy serverwill forward requests it receives to one or more other directory serversfor further processing.

A directory server and a directory proxy server typically generateaccess logs in a text file or in a relational database, and these accesslogs have one log record for each request received by the directoryserver or directory proxy server.

A directory-enabled access control system comprises a set of middlewarecomponents which rely upon a directory server to maintain informationabout the users in an enterprise, in particular each user'sauthentication credentials and access rights.

Typically, an implementation of a directory-enabled access controlsystem in the prior art will, when a user attempts to authenticate byproviding their name and credential, send a search request to adirectory server to locate the entry for that user. If an entry is foundfor that user, then the implementation either may read an attributecontaining a credential from the returned directory entry and comparethat credential with a credential presented by the user, or theimplementation may send a bind request to the directory server toperform the comparison, in which the bind request comprises thedistinguished name of the entry and the credential supplied by the user.

OBJECTS AND ADVANTAGES

Some existing implementations of directory-enabled access controlsystems update a user's directory entry when that user successfully logsin, by sending a modify request to the directory for the entrycorresponding to the user. That modify request will cause the directoryserver to replace an attribute in that user's entry which represents theuser's last login time with the current date and time. The limitationsof this prior art approach include:

-   -   Unlike processing a search or bind request, a directory server        processing a modify request must write the change to disk        storage, which will increase latency and response time in        processing authentication.    -   Many enterprise directory service deployments have a distributed        directory service, in which many directory servers replicate the        same content, either through a directory replication protocol        such as DISP or through a metadirectory. A directory server        which processes a modify request must replicate this change to        all other directory servers in the deployment, and this may lead        to poor directory server performance and high network        utilization when there is a large community of users represented        in the database. Furthermore, in deployments implementing        multi-master replication (MMR), should two or more modifications        be sent to more than one directory server for the same entry,        the MMR algorithm implemented by the directory servers may        detect a conflict between the modifications, and correct the        conflict by replacing the value with a value for the last login        date that is not the most recent date among the conflicting        values.    -   Many schemas do not define an attribute for representing a        user's last login time.    -   Since, as a search request or a bind request does not update the        target user's entry, when directory-enabled access control        systems that only send search and bind requests (and no modify        requests) to the directory to authenticate a user are part of a        deployment, it is not possible to read from a user's entry any        attribute that would indicate when a user last logged in.

It is an advantage of this invention that it can detect authenticationattempts performed by the access control component which are realized assearch requests.

It is an advantage of this invention that it does not incorrectlycategorize a user as having an inactive account should a networkpartition prevent the records for authentications from that user at adirectory server from being transferred to the unused account detectioncomponent.

SUMMARY

This invention defines and implements an approach to determine the lastlogin date and time of a user, and thus determine whether that user'saccount is still active. In this approach, a log parsing agent collectslog information from each directory server and each directory proxyserver. The log parsing agent then filters this log information andsends it to a central unused account detection component foraggregation. The unused account detection component uses the aggregatedlog information to trim a set of directory entries representing all theusers in a deployment into a resulting set of entries, which correspondto users with unused accounts.

DRAWINGS—FIGURES

FIG. 1 is a diagram illustrating the components of the system fordetecting unused accounts in a distributed directory service.

FIG. 2 is a diagram illustrating the prior art components of adirectory-enabled access control system.

FIG. 3A, FIG. 3B, and FIG. 3C are a flowchart that illustrates thealgorithm used in a log parsing agent component.

FIG. 4A and FIG. 4B are a diagram that illustrates the contents of a LPAdatabase component.

FIG. 5A, FIG. 5B and FIG. 5C are a flowchart that illustrates thealgorithm used in an unused account detection component.

FIG. 6 is a diagram that illustrates the contents of a UAD databasecomponent.

FIG. 7 is a diagram illustrating the typical components of a servercomputer.

FIG. 8 is a diagram illustrating the typical components of an enterprisenetwork and computer systems of a directory-enabled access controlsystem deployment that spans multiple physical locations.

REFERENCE NUMERALS

-   -   10 client application component    -   12 access control component    -   14 directory server component    -   16 directory server component    -   18 LPA database component    -   20 log parsing agent component    -   22 log parsing agent component    -   24 LPA database component    -   26 unused account detection component    -   28 UAD database component    -   30 user    -   32 administrator    -   40 client application component    -   42 access control component    -   44 directory server component    -   46 directory server component    -   130 authenticator table    -   132 bind pattern table    -   134 search pattern table    -   136 element set table    -   138 log status table    -   240 identity table    -   242 agent table    -   300 server computer    -   302 CPU    -   304 hard disk interface    -   306 system bus    -   308 BIOS ROM    -   310 hard disk    -   312 operating system software and state stored on hard disk    -   314 application software and state stored on hard disk    -   316 RAM    -   318 operating system software and state in RAM    -   320 application software and state in memory    -   322 network interface    -   324 LAN switch    -   400 network switch    -   402 administrator workstation computer    -   404 directory server computer    -   406 UAD server computer    -   408 time server computer    -   410 access server computer    -   412 router    -   414 client computer    -   416 directory proxy server computer    -   418 WAN    -   420 router    -   422 network switch    -   424 directory server computer

DETAILED DESCRIPTION

The invention comprises the following components:

-   -   a client application component (10),    -   an access control component (12),    -   a directory proxy server component (14),    -   a directory server component (16),    -   a log parsing agent component (20, 22),    -   an LPA database component (18, 24),    -   an unused account detection component (26), and    -   a UAD database component (28).

The client application component (10) is a software component thatrelies upon an access control component (12) to assist in the process ofauthenticating the users of the client application. A user willtypically begin the authentication process to a client application byproviding their userid and an authentication credential, such as theirpassword. The client application component will provide the userid andcredential to the access control component via an applicationprogramming interface (API), a system call, or a network protocol. Theaccess control component will respond to the client applicationcomponent with an indication of whether the user has been successfullyauthenticated.

The access control component (12) is a software component that providesan authentication and access control service to the client applicationcomponent (10). The access control component will establish connectionsto one or more directory server (16) or directory proxy server (14)components. In order to authenticate a user who is accessing a clientapplication, the access control component will submit one or more DAP orLDAP requests over these connections, in which the request locates adirectory entry for the user, and either validates the user'sauthentication credential against that directory entry, or retrieves thestored authentication credential from the directory entry.

The directory proxy server component (14) is a software component thatforwards requests it receives from the access control component to oneor more directory servers for further processing. When the directoryproxy server forwards a request to a directory server or receives aresponse from a directory server, the directory proxy server will writethe parameters of the request or response in its access log. Thedirectory proxy server is used in the situation of directory serverswhich do not generate an access log of search or bind requests. In thissituation, a directory proxy server can be placed between the accesscontrol and the directory server, and the directory proxy server will beconfigured to generate the access log.

The directory server component (16) is a software component thatimplements the server side of a directory access protocol, such as DAPor LDAP. The directory server component maintains a directoryinformation tree of one or more directory entries. Each user of a clientapplication is represented by a directory entry in the directoryinformation tree.

The log parsing agent component (20, 22) is a software component thatcollects and processes access log information. A log parsing agent isinstalled on each server computer where a directory server or directoryproxy server is installed, to collect access log information from thatdirectory server or directory proxy server. The log parsing agentretrieves patterns from the LPA database (18, 24), which is configuredwith a set of patterns that indicate the forms of bind and searchoperations generated by the access control component when itauthenticates a user. Each log parsing agent has access to a pattern foreach directory-enabled access control component present in thedeployment that relies upon the directory server or directory proxyserver whose log is monitored by that log parsing agent. The behavior ofthe log parsing agent component is illustrated by the flowchart of FIG.3A, FIG. 3B and FIG. 3C.

The LPA database component (18, 24) is a software component thatmaintains the persistent state of the log parsing agent component. TheLPA database can be implemented as a relational database, whichcomprises five tables: the authenticator table (130), the bind patterntable (132), the search pattern table (134), the element set table (136)and the log status table (138). The structure of these tables isillustrated by the diagrams of FIG. 4A and FIG. 4B.

There is one row in the authenticator table (130) for each accesscontrol component (12) in the deployment. Rows in this table are createdby the administrator. The primary key of this table is the AUTHENTICATORID column. The columns of this table are:

-   -   AUTHENTICATOR ID: a unique identifier for the access control        component,    -   SOURCE ADDRESS: the network address, such as an Internet        Protocol (IP) address of the server computer where the access        control component is installed,    -   SOFTWARE VERSION: an identifier for the software package and        version which implements the access control component, and    -   STATUS: an indication of the configured status of the access        control component.

Examples of values used in the STATUS column in rows in theauthenticator table (130) include “disabled”, to indicate that theaccess control component has been temporarily disabled, and “deleted”,to indicate that the access control component has been permanentlydisabled. A NULL value in the STATUS column indicates that accesscontrol component is active.

There is one row in the bind pattern table (132) for each access controlcomponent in the deployment which uses a bind request to authenticate aclient. Rows in this table are created by the administrator. The primarykey of this table is the PATTERN ID column. The columns of this tableare:

-   -   PATTERN ID: a unique identifier for the pattern,    -   SOURCE ADDRESS: either the network address, such as an Internet        Protocol (IP) address of the server computer where the access        control component using this pattern is installed, or NULL if        there are multiple server computers on which an access control        component using this pattern is installed,    -   BASE DN: a distinguished name of the subtree of the directory        information tree in which the entries for users are located,    -   MATCH TYPE: the attribute type of the attribute value assertion        in the least significant component of the distinguished name        supplied in the bind request, for which the assertion value is        the userid of the user,    -   STATUS: an indication of the configured status of this pattern;        a NULL value indicates this pattern is active, and    -   AUTHENTICATOR ID: a unique identifier for the access control        component.

There is one row in the search pattern table (134) for each accesscontrol component in the deployment which uses a search request toauthenticate a client. Rows in this table are created by theadministrator. The primary key of this table is the PATTERN ID column.The columns of this table are:

-   -   PATTERN ID: a unique identifier for the pattern,    -   SOURCE ADDRESS: either the network address, such as an Internet        Protocol (IP) address of the server computer where the access        control component using this pattern is installed, or NULL if        there are multiple server computers on which an access control        component using this pattern is installed,    -   BIND DN: either a distinguished name with which the access        control component authenticates itself to the directory before        performing search operations, or NULL if there are multiple        access control components using this pattern,    -   SEARCH BASE: either a distinguished name of the baseObject field        of the search request sent by the access control component if        the search scope is “singleLevel” or “wholeSubtree”, or NULL if        the search scope is “baseObject”,    -   SEARCH SCOPE: the search scope in the search request sent by the        access control component, one of “baseObject”, “singleLevel” or        “wholeSubtree”,    -   FILTER PATTERN: a regular expression matching a string encoding        the search filter sent by the access control component,    -   MATCH TYPE: the attribute type in an equality match filter in        the search filter sent by the access control component, in which        the assertion value is the user id of the user being        authenticated,    -   REQUESTED TYPES: either a set of attribute types in the        attributes field of the search request sent by the access        control component, or NULL if the attributes field is not        relevant to matching the pattern,    -   STATUS: an indication of the configured status of this pattern:        a NULL value indicates this pattern is active, and    -   AUTHENTICATOR ID: a unique identifier for the access control        component.

There is one row in the element set table (136) for each record to betransferred to the unused account detection component. Rows are added toand removed from this table by the log parsing agent component. Theprimary key of this table is the ELEMENT ID column. The columns of thistable are:

-   -   ELEMENT ID: a unique identifier for the element,    -   DATE: the date and time of the log record,    -   OPERATION: an indication of the directory operation represented        by this element,    -   PATTERN ID: either the unique identifier of the pattern which        matched the log record, or NULL if a pattern was not matched,        and    -   TARGET: the userid of the affected user.

There is one row in the log status table (138). This row is updated bythe log parsing agent component. The columns of this table are:

-   -   PARSE DATE: the date and time of the last parse of the directory        server or directory proxy server access log, and    -   CHECKPOINT: the index into the directory server or directory        proxy server access log of the last record read by the log        parsing agent component.

The unused account detection component (26) is a software component thatreceives element sets from one or more log parsing agent components (20,22) via a network connection. The network connection comprises anapplication layer protocol exchange, carried within a secure socketslayer session layer protocol exchange which provides encryption, such asthe secure sockets layer protocol Transport Layer Security (TLS)protocol described in the document “The Transport Layer Security (TLS)Protocol Version 1.1” by T. Dierks et al of April 2006, carried withinthe Transmission Control Protocol (TCP) on an Internet Protocol(IP)-based computer network. The unused account detection componentupdates the UAD database (28) identity and agent tables. The unusedaccount detection component is configured with a time interval for userinactivity, for example 30 days, and a time interval for log parsingagent contact, such as one day. The behavior of this component isillustrated by the flowchart of FIG. 5A, FIG. 5B and FIG. 5C.

The UAD database component (28) is a software component that maintainsthe persistent state of the unused account detection component. The UADdatabase can be implemented as a relational database, which comprisestwo tables: the identity table (240) and the agent table (242). Thestructure of these tables is illustrated by the diagram of FIG. 6.

There is one row in the identity table (240) for each user that accessesthe client application component. The primary key of this table is theUSER ID column. The columns of this table are:

-   -   USER ID: a unique identifier for the user,    -   USER NAME: the name of the user,    -   LAST LOGIN ATTEMPT DATE: the date and time of the most recent        login attempt by that user as known by the unused account        detection component, and    -   STATUS: an indication of the status of the user, one of NULL for        an active user account, “inactive” for an inactive user account,        “disabled” for an account that has been temporarily disabled by        the administrator, and “deleted” for an account that has been        deleted by the administrator.

Initially, rows are added to the identity table (240) for each user. Ineach row, the initial value of the LAST LOGIN ATTEMPT DATE column is setto the current date and time, and the value of the STATUS column is setto NULL.

There is one row in the agent table (242) for each log parsing agent.The primary key of this table is the AGENT ID column. The columns ofthis table are:

-   -   AGENT ID: a unique identifier for the log parsing agent,    -   LAST CONTACT DATE: the date and time of the last contact        received from the log paring agent, and    -   STATUS: an indication of the status of the log parsing agent.

The processing components of this invention can be implemented assoftware running on computer systems on an enterprise computer network.

FIG. 8 illustrates an example enterprise computer network. At one site,an administrator workstation computer (402), a directory server computer(404), a UAD server computer (406), a time server computer (408), anaccess server computer (410), a client computer (414), a directory proxyserver computer (416) and a router (412) are attached to a networkswitch (400). The router (412) at that site connects to another router(420) at a different site via a wide area network (418). At that othersite, the router (420) and a directory server computer (424) areconnected to a network switch (422). In this enterprise computernetwork, the client application (10) can be implemented as softwarerunning on the client computer (414), the access control component (12)can be implemented as software running on an access server computer(410), the directory proxy server (14) can be implemented as softwarerunning on a directory proxy server computer (416), the directory servercomponent (16) can be implemented as software running on the directoryserver computers (404 and 424), the LPA database (18) and log parsingagent (20) can be implemented as software running on a directory proxyserver computer and directory server computers, and the unused accountdetection component (26) and UAD database (28) can be implemented assoftware running on the UAD server computer (406). The time servercomputer (408) communicates with the other computers in the enterprisenetwork using a protocol such as the Network Time Protocol (NTP) tomaintain time synchronization.

FIG. 7 illustrates the typical components of a server computer (300).Components of the computer include a CPU (302) a system bus (306), ahard disk interface (304), a hard disk (310), a BIOS ROM (308), randomaccess memory (316), and a network interface (322). The networkinterface connects the computer to a local area network switch (324).The hard disk (310) stores the software and the persistent state of theoperating system (312) and applications (314) installed on thatcomputer. The random access memory (316) holds the executing softwareand transient state of the operating system (318) and applicationprocesses (320).

Operations

The log filtering agent component comprises a single thread ofexecution. At step 62, the thread will create an empty element set byinitializing the element set table (136). At step 64, the thread willread the log checkpoint from the log status table (138) and compare thischeckpoint with the access log of the directory server or directoryproxy server. At step 68, the thread will test whether there are unreadaccess log records which the log parsing agent has not yet processed. Ifthere are no unprocessed log records, then at step 70 the thread willwait for log updates from the directory server or directory proxyserver, or until a timeout period is reached.

At step 72, the thread will traverse each log record in the log of thedirectory server or directory proxy server that has not yet been handledby the log parsing agent. At step 74, the thread will parse the recordfrom the log. At step 80, the thread will test whether the log record isa bind operation or a search operation. If it is a bind operation, thenthe thread will search the bind pattern table (132) for a row in which:the value of the SOURCE ADDRESS column, if not NULL, matches the networkaddress of the directory access protocol client, the value of the BASEDN column is a suffix of the distinguished name of the request, thevalue of the MATCH TYPE column matches an attribute type in the leastsignificant relative distinguished name of the bind request, and thevalue of the STATUS column is NULL. If it is a search operation, thenthe thread will search the search pattern table (134) for a row inwhich: the value of the SOURCE ADDRESS column, if not NULL, matches thenetwork address of the directory access protocol client, the value ofthe BIND DN, if not NULL, matches the distinguished name by which theclient authenticated to the directory server, the value of the SEARCHBASE column, if not NULL, matches the baseObject field of the searchrequest, the value of the SEARCH SCOPE column matches the scope field ofthe search request, the value of the FILTER PATTERN column matches thefilter of the search request, the value of the MATCH TYPE column is anattribute type of an equality filter in the filter in the searchrequest, the value of the REQUESTED TYPES column, if not NULL, matchesthe value of the attributes field of the search request, and the valueof the STATUS column is NULL. At step 84, the thread will test whetherone or more rows were found in either the bind pattern table or thesearch pattern table. If no search was performed or no rows were found,then at step 86 the thread will test whether the operation is a deleteoperation or an operation, such as a modify, which changes the state ofthe user. If so, then the thread will continue at step 90. If no searchwas performed, no rows were found, and the operation is not a deleteoperation or does not change the state of the user, then the thread willcontinue at step 92. If the search was performed and one or more rowswere found, then at step 88, the thread will process record by patternto extract the userid of the user being authenticated. At step 90, thethread will add an element to the element set table (136) for therecord. After the records have been handled, the thread will continue atstep 100.

At step 100, the thread will test whether it has a connection to theunused account detection component. If it does not have a connection,then at step 102 the thread will establish a connection to the unusedaccount detection component. If the connection establishment failed,then at step 106 the thread will report an error, and continue to step66. At step 108, the thread will send the element set to the unusedaccount detection component over the connection. At step 110, the threadwill test whether the unused account detection component successfullyreceived the element set. If the unused account detection component didnot successfully receive the element set, then at step 112 the threadwill report an error; at step 114 the thread will close the connection,and the thread will continue at step 66. Otherwise, at step 116, thethread will close the connection, clear the element set, and save thelog state to the log status table (138). The thread will then continueat step 66.

The unused account detection component (26) has a single thread ofexecution. At step 152, the thread will set the initial value of theLAST LOGIN ATTEMPT DATE column in each row of the identity table (240)to the current date and time, and set the initial value of the LASTCONTACT DATE column in each row of the agent table (242) to the currentdate and time. At step 156, the thread will wait, either until aconnection is attempted from a log parsing agent, or until a timer eventoccurs. The timer is set to the log parsing agent contact interval. If atimer event occurred, then the thread will continue at step 190.Otherwise, at step 160, the thread will receive an element set from alog parsing agent over the connection, and then close the connection. Ifthe element set transfer failed, then the thread will loop back to step156. Otherwise, at step 164 the thread will set the value in the LASTCONTACT DATE column for the row in the agent table (242) for the logparsing agent to the current date and time. At step 166, the thread willtraverse the elements in the element set. At step 168, the thread willparse the element, extract the userid of the user from the element, andsearch the identity table (240) for a row in which that userid matches avalue of the USER ID column. At step 180, the thread will test whether arow was found. If a row is found, then at step 182 the thread will testwhether the date and time in the value of the LAST LOGIN ATTEMPT DATE inthe row is more recent than the date in the element. If an identity isfound and the date and time in the row is not more recent than the dateand time in the element, then at step 184, the thread will set the valueof the LAST LOGIN ATTEMPT DATE column of the row in the identity tableto the date and time of the element. At step 186, the thread will loopback to step 168 until all elements of the element set have beenprocessed.

At step 190, the thread will search the agent table (242) for rows inwhich the value of the STATUS column is NULL. If one or more rows have avalue in the LAST CONTACT DATE that is older than the configured logparsing agent interval, then the thread will loop back to step 156.Otherwise, at step 194 the thread will traverse the log parsing agentsrepresented by the rows of the agent table (242). At step 210, thethread will compute the time difference between the current date andtime and the last contact date and time of the agent from the value ofthe LAST CONTACT DATE column. After all the rows for the log parsingagents have been traversed, at step 214, the thread will select thelargest of the time differences calculated, add the user inactivity timeinterval to this largest time difference to form a sum, and set aninactivity date and time to be this sum subtracted from the current dateand time. At step 216, the thread will search the identity table (240)for rows in which the value of the STATUS column is NULL. At step 218,the thread will traverse each user record in the identity table. At step220, the thread will compare the user's last login date and time fromthe value of the LAST LOGIN ATTEMPT DATE column with the inactivity dateand time. At step 224, the thread will test whether the value of theLAST LOGIN ATTEMPT DATE column is earlier than the inactivity date andtime. If the value is earlier, then at step 226 the thread will updatethe row in the identity table by setting the value of the STATUS columnto “inactive”. At step 228, the thread will loop back until each recordhas been processed. The thread will then continue at step 154.

CONCLUSIONS

Many different embodiments of this invention may be constructed withoutdeparting from the scope of this invention. While this invention isdescribed with reference to various implementations and exploitations,and in particular with respect to systems for monitoring the last logintimes of users with accounts in a distributed directory service, it willbe understood that these embodiments are illustrative and that the scopeof the invention is not limited to them.

1. A method of determining whether a user account has been recently usedin authentication to a client application in a distributed systemdeployment, said method comprising: (a) transmitting over a directoryaccess protocol a request from an access control component to adirectory server, (b) logging by said directory server of a usernameparameter of said request identifying said user account and an accesstime as an element in an access log, (c) transmitting over anapplication protocol said element from a log parsing agent component toan unused account detection component, (d) updating an access time of arecord corresponding to said user account in a database attached to saidunused account detection component with said access time from saidelement transmitted from said log parsing agent, and (e) comparing saidaccess time of said record with a minimum inactivity time.
 2. The methodof claim 1, wherein said directory access protocol is a lightweightdirectory access protocol.
 3. The method of claim 1, wherein saidrequest is a bind request.
 4. The method of claim 1, wherein saidrequest is a search request.
 5. The method of claim 1, wherein saidtransmitting over said application protocol comprises communicating overa secure sockets layer session connection.
 6. The method of claim 1,wherein said minimum inactivity time is earlier than the least recenttime of connection from a log parsing agent to said unused accountdetection component in said distributed system deployment.
 7. A systemfor determining whether a user account has been recently used inauthentication to an application in a distributed system deployment,said system comprising (a) a client application, (b) an access controlcomponent, (c) a directory server, (d) a log parsing agent component,(e) an unused account detection component, and (f) a database attachedto said unused account detection component, wherein said clientapplication transmits an identity of a user to said access controlcomponent, said access control component transmits a request with ausername parameter identifying an account of said user via a directoryaccess protocol to said directory server, said directory server logssaid username parameter of said request and an access time as an elementin an access log, said log parsing agent component parses said elementfrom said log and transmits over an application protocol said element tosaid unused account detection component, said unused account detectioncomponent updates an access time of a record corresponding to said useraccount in said database attached to said unused account detectioncomponent with said access time from said element transmitted from saidlog parsing agent, and said unused account detection component comparessaid access time of said record with a minimum inactivity time.
 8. Thesystem of claim 7, wherein said client application, said access controlcomponent, said directory server, said log parsing agent component, saidunused account detection component and said database are implemented assoftware running on a general-purpose computer system.
 9. The system ofclaim 7, wherein said access control component transmits said request tosaid directory server via a lightweight directory access protocol. 10.The system of claim 7, wherein said request is a bind request.
 11. Thesystem of claim 7, wherein said request is a search request.
 12. Thesystem of claim 7, wherein said log parsing agent component transmitsover said application protocol comprising a secure sockets layer sessionconnection.
 13. The system of claim 7, wherein said minimum inactivitytime is earlier than the least recent time of connection from a logparsing agent to said unused account detection component in said system.14. A computer program product within a computer usable medium withsoftware for determining whether a user account has been recently usedin authentication to an application in a distributed system deployment,said computer program product comprising: (a) instructions fortransmitting over a directory access protocol a request from an accesscontrol component to a directory server, (b) instructions for logging bysaid directory server of a username parameter of said requestidentifying said user account and an access time as an element in anaccess log, (c) instructions for transmitting over an applicationprotocol said element from a log parsing agent component to an unusedaccount detection component, (d) instructions for updating an accesstime of a record corresponding to said user account in a databaseattached to said unused account detection component with said accesstime from said element transmitted from said log parsing agent, and (e)instructions for comparing said access time of said record with aminimum inactivity time.
 15. The computer program product of claim 14,wherein said instructions for transmitting over said directory accessprotocol comprise instructions for transmitting over a lightweightdirectory access protocol.
 16. The computer program product of claim 14,wherein said instructions for transmitting over said applicationprotocol comprise instructions for transmitting over an applicationprotocol comprising a security sockets layer session connection.